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A  Key  Notarization   System   For  Computer  Networks 

Miles    E.  Smid 


A  cryptographic,  Key  Notarization  System  is 
proposed  for  computer  networks  to  protect  personal 
(nonshared)  files,  to  communicate  securely  both  on 
and  off-line  with  local  and  remote  users,  to  pro- 
tect against  key  substitution,  to  authenticate 
system  users,  to  authenticate  data,  and  to  provide 
a  digital  signature  capability  using  a  nonpublic 
key  encryption  algorithm.  The  system  is  imple- 
mented by  the  addition  of  key  notarization  facili- 
ties which  give  users  the  capability  of  exercising 
a  set  of  commands  for  key  management  as  well  as 
for  data  encryption  functions.  Key  notarization 
facilities  perform  notarization  which,  upon  en- 
cryption, seals  a  key  or  password  with  the  identi- 
ties  of   the   transmitter   and   Intended  receiver. 

Key  words:  Cryptography;  digital  signatures; 
encryption;  identifiers;  key  management;  key 
notarizat  ion . 


1.  INTRODUCTION 


This  paper  proposes  a  Key  Notarization  System  (KNS) 
which  may  be  used  in  conjunction  with  a  cryptographic  device 
to  provide  increased  data  security.  In  1977  the  National 
Bureau  of  Standards  published  a  completely  defined  encryp- 
tion algorithm  known  as  the  Data  Encryption  Standard  (DES) 
which  became  a  Federal  standard  for  the  protection  of  un- 
classified data  [2].  Since  publication,  several  companies 
have  produced  hardware  devices  which  implement  the  standard, 
and  there  has  been  an  increased  awareness  that,  in  certain 
applications,  encryption  offers  the  only  effective  means  of 
protecting  information.  The  first  applications  of  the  en- 
cryption of  unclassified  data  appeared  in  the  area  of  elec- 
tronic funds  transfer,  but  the  passage  of  the  Privacy  Act  of 
1974  (5  use  522a)  and  Transmittal  Memorandum  No.  1  to  Office 
of  Management  and  Budget  Circular  A-71  placed  added  respon- 
sibilities on  Federal  data  systems  for  the  protection  of 
nonfinancial   data  as  well. 
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Even  before  the  DES  was  adopted,  it  was  clear  that 
there  was  more  to  cryptographic  security  than  a  secure  en- 
cryption algorithm.  Efforts  were  initiated  by  NB S  to  have 
additional  standards,  based  on  the  DES,  developed.  An  area 
which  needed  to  be  addressed  was  secure  key  management.  DES 
keys  are  64-bit  binary  vectors  which  are  individually 
selected  in  order  to  provide  the  unknown  quantity  necessary 
for  security  in  the  encryption  algorithm.  Key  management 
involves  the  secure  generation,  distribution,  and  storage  of 
cryptographic  keys.  If  the  key  management  is  weak,  then  the 
most  secure  cryptoalgor ithm  will  be  of  little  value.  In 
fact,  a  very  strong  cryptoalgorithm  used  in  a  weak  key 
management   system  can  give   a   false   sense   of  security. 

Previous  work  on  key  management  systems  may  be  found  in 
Ehrsam,  et  al  [4]  and  Everton  [5].  This  paper  develops  a 
simple  key  hierarchy  and  a  set  of  commands  or  protocols 
which  in  conjunction  with  a  secure  random  key  generator  and 
a  strong  encryption  algorithm  may  be  used  to  generate  and 
store  keys  as  well  as  to  encrypt  and  decrypt  data.  These 
commands  have  been  devised  for  computer  systems  which  employ 
key  notarization  facilities  (KNF's).  They  are  to  be  tested 
on  the  NBS  UNIX  system  but  they  are  not  UNIX  dependent.  It 
is  intended  that  the  system  be  applicable  to  many  different 
situations.  On-line  communications,  file  encryption,  off- 
line mail,  and  digital  signatures  all  are  to  be  protected. 
Key  notarization  is  presented  to  help  provide  security  while 
maintaining   the   required  flexibility. 


2.  REQUIREMENTS 

The  Key  Notarization  System  (KNS)  may  be  used  in  com- 
puter networks  along  with  key  notarization  facilities 
(KNF's)  to: 

1.  Securely  communicate   between  any  two  users; 

2.  Securely  communicate   via  encrypted  mail  (off-line); 

3.  Protect   personal    (nonshared)  files; 

4.  Provide  a   digital    signature  capability. 


Secure  communication  involves  preventing  the  disclosure 
of  plain  text,  detecting  fraudulent  message  modification, 
detecting  fraudulent  message  insertion  or  deletion,  and 
detecting     fraudulent      replay  of   a   previously  valid  message. 
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The  KNS  must  be  consistent  with  these  goals  and  yet  operate 
at   speeds   sufficient   for   normal   network  communications. 


With  mail  encryption,  data  is  encrypted  and  then  sent 
via  mail  or  some  means  which  cannot  provide  an  immediate 
response.  The  data  is  stored  in  the  encrypted  form  until 
decryption  at  some  later  time.  In  this  situation  one  cannot 
have  an  interactive  system  for  exchanging  keys  because  no 
real-time  response  is  possible.  Therefore,  protocols  must 
be  devised  so  that  the  receipt  of  keys  need  not  be  immedi- 
ately acknowledged. 

Once  encrypted,  personal  files  can  only  be  decrypted  by 
the  original  owner.  They  are  encrypted  for  secure  storage 
rather  than  secure  communication.  In  this  case  encryption 
Is  used  to  protect  against  accidental  disclosure,  such  as 
spillage,  and  intentional  disclosure,  such  as  scavenging. 
It  is  often  desirable  that  the  data  encrypting  key  be  stored 
with  the  cipher  for  ease  of  recovery.  Of  course,  the  key 
would  be  encrypted  under  another  long  term  key  which  is  kept 
for  the  user  either  in  the  KNF  or  in  a  secure  location  from 
which   it  may  be  entered   into   the  KNF. 

Digital  signatures  were  developed  in  conjunction  with 
public  key  systems.  (See  Dlffie  and  Hellman  [3]  and  Rivest, 
et  al  [8].)  In  such  systems  the  decryption  key  is  not  equal 
to,  and  cannot  be  computed  from,  the  encryption  key.  En- 
cryption keys  may  be  made  public  while  decryption  keys  are 
kept  secret.  A  digital  signature  is  decrypted  using  the 
secret  decryption  key  and  sent  to  the  receiver.  The  re- 
ceiver may  encrypt,  using  the  public  key,  and  verify  the 
signature,  but  the  signature  cannot  be  forged  since  only  the 
transmitter  knows  the  secret  decryption  key.  (The  cryptoal- 
gorithm  must  have  the  property  that  decryption  of  the  signa- 
ture followed  by  encryption  equals  the  original  signature.) 
Popek  and  Kline  [7]  showed  that  nonpublic  key  algorithms  can 
also  be  used  for  digital  signatures  in  conjunction  with  a 
"Network  Registry".  In  the  KNS,  a  different  method  is  pro- 
posed for  Implementing  digital  signatures  with  the  DES  non- 
public  key  algorithm. 
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3.      SYSTEM  DESIGN 


3.1      THE  NETWORK 

The  KNS  is  designed  for  computer  networks  which  consist 
of  host  computers,  user  terminals,  and  key  notarization  fa- 
cilities. Figure  1  shows  a  four  host  network.  The  host 
controls  the  normal  operation  and  communication  of  the  ter- 
minals. Terminals  have  the  capability  of  communicating  with 
the  host,  with  other  local  terminals  through  the  host,  and 
with  terminals  of  other  hosts  via  communication  channels 
called  Interchanges .  Each  terminal  will  be  able  to  use  the 
host  KNF  by  means  of  user  commands.  All  commands  will  be 
implemented  in  the  KNF,  and  every  KNF  will  have  the  capacity 
to  generate  keys  for  distribution  to  other  hosts  or  facility 
users  . 

Interchanges  may  be  electronic  communications  lines, 
microwave  links,  courier  routes,  etc.,  or  combinations  of 
more  than  one  medium.  In  Figure  1  only  host  3  shares  an  in- 
terchange with  host  4.  If  host  1  shares  a  common  inter- 
change key  with  host  4,  then  host  1  may  communicate  with 
host  4  through  host  3  without  intermediate  decryption  and 
r eencr yp t i on .  Host  3  would  merely  act  as  a  switch.  This  is 
known  as  end-to-end  encryption.  If  host  1  does  not  share  a 
common  key  with  host  4  but  does  share  a  key  with  host  3,  and 
if  host  3  shares  a  key  with  host  4,  then  host  1  may  communi- 
cate with  host  4  via  host  3.  The  cipher  would  have  to  be 
decrypted  at  host  3  and  reencrypted  in  the  key  shared 
between  host  3  and  host  4.  Care  must  be  taken  to  insure 
that  the  communications  are  not  compromised  when  unencrypt- 
ed. This  method  of  encrypted  communications  is  called  link 
encrypt  ion . 

The  lines  between  the  KNF  and  its  host  and  the  lines 
between  each  terminal  and  its  host  must  be  protected.  They 
could  be  physically  secured  or  they  could  be  secured  by  the 
addition  of  cryptographic  devices  on  each  end  of  the  links. 
When  a  user  is  editing  a  file  in  the  host,  it  is  in  plain 
text  form,  and  the  host  will  have  to  protect  the  data  from 
other  users.  Once  the  user  has  finished  editing,  he  may 
command  the  KNF  to  encrypt  the  data  and  store  the  resulting 
cipher  in  unprotected  memory  or  send  it  to  a  remote  user 
over   an  interchange. 
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3.2      THE  HOST 


We  will  assume  that  the  host  computer  has  two  types  of 
memory:  that  which  is  not  accessible  to  any  user,  called 
system  memory,  and  that  which  is  accessible  to  users,  called 
user  memory.  User  i's  memory  is  core,  disk,  etc.,  where 
user  i  is  permitted  to  store  and  recall  data.  Most  comput- 
ers have  a  means  of  protecting  system  memory  from  users,  and 
some  computers  protect  one  user  from  another  to  a  certain 
degree.  We  will  rely  on  these  protective  features  to  the 
extent  that  the  user  should  not  be  able  to  subvert  the 
operation  of  the  computer.  For  example,  the  system  must  be 
able  to  correctly  maintain  the  identity  of  the  user  once  he 
has  been  authenticated  and  given  permission  to  execute  the 
commands.  The  system  must  also  prevent  one  user  from  taking 
on  the  identity  of  another  user  and  thereby  obtaining  access 
to  his  unencrypted  data.  In  other  words,  encryption  by  it- 
self does  not  solve  the  computer  security  problem.  However, 
if  properly  used  in  a  system  with  the  necessary  protective 
features,  it  can  provide  protection  to  stored  and  communi- 
cated data. 

The  encrypted  keys  of  user  i  are  stored  in  user  i's 
memory,  and  encrypted  passwords  to  which  no  user  needs  ac- 
cess will  be  stored  in  system  memory.  Nevertheless,  we  will 
assume  that  any  user  could  gain  read  and  write  access  to 
every  encrypted  password  stored  in  system  memory.  Each  user 
is  expected  to  manage  the  encrypted  keys  which  belong  to 
him,  but  he  will  not  know  any  clear  keys.  Yet,  key  encryp- 
tion is  not  sufficient.  A  method  is  required  to  protect 
against  key  substitution  and  to  insure  that  each  user 
correctly   identifies   the   user  with  whom  he   is  communicating. 

3.3     THE  KEY   NOTARIZATION  FACILITY  (KNF) 

The  KNF  contains  a  DES  encryption  device.  It  will  have 
a  control  microprocessor  and  memory  to  implement  commands 
and  data  transfers.  The  KNF  must  also  store  the  unencrypted 
interchange  keys  and  the  states  of  active  users.  An  active 
state  consists  of  a  user  identifier  along  with  an  initiali- 
zation vector  and  an  unencrypted  data  key  for  both  transmit- 
ting and  receiving  data.  A  user  is  active  as  soon  as  his 
identifier  is  loaded  into  active  user  memory  in  the  KNF.  He 
may  then  proceed   to   load   the   rest   of  his  state. 

The  KNF  contains  a  key  generator  which  is  capable  of 
generating  unpredictable  keys.  At  any  time  a  user  should  be 
able  to  predict  the  next  key  to  be  generated  with  only  a 
1/ (2**56)  probability  of  success  where  2**56  is  two  raised 
to  the  56'th  power.  One  possible  key  generator  is  proposed 
in     the     Appendix.        Once      the   56-bit   keys   are   generated  the 
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proper  parity  Is  determined  and  the  entire  64-bit  key  is  en- 
crypted before  it  is  returned  to  the  host.  Thus,  no  clear 
keys  are  known  outside  the  KNF .  The  key  generator  is  also 
used  to  generate  64-bit  initialization  vectors  which  ini- 
tialize the  DBS  cryptoal gor i thm .  Since  the  KNF  contains 
clear  keys,  the  encryption  algorithm,  the  commands  program, 
and   the   key  generator,    it   must   be   physically  protected. 

Cryptographic  facilities  containing  a  single  master  key 
are  used  in  Ehrsam,  et  al  [4]  to  perform  encryption  and  exe- 
cute key  management  commands.  Our  key  notarization  facili- 
ties hold  several  keys  and  the  key  generator.  They  employ  a 
different  key  hierarchy,  a  different  set  of  commands,  and 
are   the   enforcers   of   key  notarization. 


3.4      DISTRIBUTED  VERSUS  CENTRALIZED  KEY  GENERATION 

Branstad  [1]  describes  how  network  security  centers 
(NSC)  may  be  used  for  key  distribution.  Upon  request,  the 
NSC  generates  a  key  for  use  by  each  of  the  parties  in  a 
conversation.  One  copy  is  encrypted  under  a  key  shared 
between  the  NSC  and  the  first  party  and  another  copy  is  en- 
crypted under  a  key  shared  between  the  NSC  and  the  second 
party.  The  encrypted  forms  of  the  key  are  then  sent  to  the 
appropriate  receivers. 

The  KNS  uses  distributed  rather  than  centralized  key 
generation  as  employed  by  an  NSC.  In  order  to  provide  for 
off-line  encrypted  mail,  the  KNS  gives  each  host  the  capa- 
bility of  key  generation  in  its  own  KNF.  Thus,  two  hosts  do 
not  even  have  to  be  electronically  connected  in  order  to 
communicate  securely.  The  KNS  requires  fewer  protocols  be- 
cause parties  do  not  have  to  send  a  remote  key  generation 
request  and  they  do  not  have  to  respond  to  the  receipt  of  a 
key.  Fewer  protocols  mean  fewer  ways  an  enemy  can  attempt 
to  trick  or  confuse  the  communicating  parties  by  altering  or 
playing  back  the  protocol  messages.  (See  Needham  and 
Schroeder  [6].) 

If  a  KNF  is  compromised,  only  communications  Involving 
the  compromised  facility  are  compromised.  If  a  NSC  is 
compromised,  and  there  is  only  one  NSC  for  the  network,  then 
the  whole  network  is  compromised.  Finally,  with  a  local  key 
generator,  one  can  encrypt  personal  (nonshared)  files 
without  having  to  depend  on  a  remote  site.  The  KNS  approach 
has  the  disadvantage  that  the  key  generation  capability  and 
the  KNF  physical    security  has   to   be   replicated   at   each  host. 
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4.      IDENTIFIERS  AND  KEY  NOTARIZATION 


A  special  feature  of  the  KNS  is  the  support  of  key  no- 
tarization. This  feature  increases  security,  permits  a  sim- 
ple system  design,  and  provides  a  means  of  implementing  sig- 
natures with  a  nonpublic  key  system.  Ident 1 f iers  are  non- 
secret  binary  vectors  of  up  to  28  bits  which  uniquely  iden- 
tify each  user  In  the  network.  When  a  user  first  attempts 
to  call  the  KNF  he  must  submit  his  identifier  along  with  the 
correct  password  to  establish  an  active  state  in  the  KNF. 
Both  the  host  and  the  KNF  employ  identifiers  to  "recognize" 
the  users. 


Key  notarization  Is  similar  to  the  actions  of  a  notary 
public  who  first  requires  his  customer  to  identify  himself 
via  a  driver's  license,  etc.,  before  he  seals  (notarizes) 
the  customer's  signature  on  a  document  with  his  notary 
stamp.  In  addition  to  the  notary's  function  of  authenticat- 
ing the  creator  of  a  message,  the  KNS  authenticates  the  mes- 
sage Itself  and  the  person  requesting  decryption.  Key  no- 
tarization Is  similar  to  having  a  notary  public  on  each  end 
of  a   secure  communication  channel. 


Let  1  and  j  be  Identifiers  and  K  be  a  DBS  key.  Then 
(1  II  j)  represents  the  concatenation  of  1  and  j  .  K,  a  64 
bit  key,  consists  of  eight  btyes,  each  with  seven  informa- 
tion bits  and  a  parity  bit.  K  XOR  (ill  j)  is  a  special 
function  defined  as  follows.  The  leftmost  seven  information 
bits  of  K  are  exclusive  or'ed  with  the  leftmost  seven  bits 
of  1.  The  eighth  bit,  a  parity  bit,  is  then  appended  so 
that  the  modulo  2  sum  of  all  eight  bits  is  odd.  Then  the 
next  seven  Information  bits  of  K  are  exclusive  or'ed  with 
the  next  seven  bits  of  1  and  the  correct  parity  bit  is  ap- 
pended. This  continues  until  the  last  seven  information 
bits  of  K  have  been  exclusive  or'ed  with  the  last  seven  bits 
of  j  and  the  final  parity  bit  has  been  set.  Therefore,  K 
XOR  (1  II  j)  Is  a  valid  DES  key  with  56  information  bits  and 
eight   parity  bits. 

All  passwords  and  data  keys  are  encrypted  under  K  XOR 
(1  II  j)  for  some  K  and  some  1,  j  pair.  In  the  casu  of 
passwords  1  =  j.  This  adds  to  security  because  one  user 
cannot  substitute  his  password  or  keys  for  those  of  another 
user  and  be  able  to  authenticate  or  decrypt  as  that  user. 
This  will  be  explained  in  detail  in  section  7,  PASSWORD  AND 
KEY  STORAGE.  The  security  is  also  increased  because  both 
parties  in  a  conversation  must  know  the  other's  correct 
identity  to  communicate.  Since  the  KNF  only  needs  to  retain 
keys  for  each  Interchange,  Instead  of  each  user,  the  network 
design  is  simplified;  and  since  only  one  user  can  encrypt 
with     a     given  data  key  and   only  one   user   can  decrypt   with  a 
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given  data  key,  a  signature  system  may  be  devised  similar  to 
those  used  with  public  key  encryption  systems.  This  will  be 
discussed   further   in   section   10,    DIGITAL  SIGNATURES. 

When  key  notarization  is  used,  keys  and  passwords  are 
sealed,  upon  encryption  by  the  KNF,  with  the  identifiers  of 
the  transmitter,  or  key  generator,  and  the  receiver.  To 
generate  a  notarized  key  the  transmitter  must  Identify  him- 
self to  the  KNF  and  provide  proof  of  his  identity  by  supply- 
ing his  correct  password.  We  call  this  user  authentication. 
He  must  also  identify  the  intended  receiver  of  the  key. 
Once  encrypted,  the  correct  key  cannot  be  decrypted  unless 
the  correct  identifier  pair  is  again  provided.  To  decrypt 
the  key  the  receiver  identifies  himself  and  provides  pass- 
word proof  of  his  identity.  The  receiver  must  also  supply 
the  identity  of  the  transmitter  which  may  have  been  sent 
unencrypted.  If  the  identification  information  is  not  the 
same  as  that  provided  by  the  transmitter  to  his  KNF,  then 
the  decrypted  key  will  not  equal  the  original  key  and  no  in- 
formation can  be  correctly  decrypted.  Thus,  the  receiver 
must  know  the  correct  transmitter  and  be  the  intended  re- 
ceiver. 


5.      USER  AUTHENTICATION 


Each  user  will  have  a  password  which  is  used  to  authen- 
ticate the  user  and  permit  him  to  invoke  user  commands.  The 
plain  password  is  passed  through  an  encryption  function,  in- 
volving the  user's  identifier,  and  the  result  is  compared 
with  a  stored  value  before  the  user  is  activated.  There- 
fore, a  user  cannot  exercise  any  other  command  until  his 
identity  has  been  authenticated.  The  password  of  each  user 
is  stored  in  system  memory  encrypted  under  the  facility  in- 
terchange key  (See  section  6,  KEY  HIERARCHY.)  combined  with 
the  user's  identifier.  Since  it  is  assumed  that  the  host 
can  maintain  the  correct  identity  of  a  user  once  he  has  been 
authenticated,  the  user  need  not  resubmit  his  password  for 
each  key  he  generates  while  he  is  active.  His  authenticated 
identifier  which  has  been  loaded  into  active  user  memory 
will   automatically  be   used   as  his  identifier. 
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6.      KEY  HIERARCHY 


Two  distinct  types  of  keys  are  used  to  form  the  key 
hierarchy,  Interchange  keys  (IK's)  and  data  keys  (DK's). 
Interchange  keys  encrypt  passwords  (PW's)  and  data  keys, 
while  data  keys  encrypt  both  data  and  initialization  vectors 
(IV's).      The   key  hierarchy   is   shown  below. 


6.1      INTERCHANGE  KEYS  (IK's) 

Interchange  keys  are  used  for  the  exchange  of  keys 
between  users.  One  interchange  key,  called  the  facility 
interchange  key,  is  used  for  communication  within  a  facility 
and  the  encryption  of  facility  user  passwords.  Other  inter- 
change keys  may  be  available  for  the  exchange  of  data  keys 
between  facilities  or  for  special  subgroups  of  a  facility. 
IK's  are  generated  outside  the  network  and  are  entered, 
unencrypted,  directly  into  the  KNF.  This  permits  two  facil- 
ities to  enter  the  same  IK.  One  IK  can  be  used  to  connect 
all  the  users  of  two  hosts  since  a  user  may  not  decrypt  a 
data  key  shared  by  two  other  users.  This  is  because  the 
identifiers  of  the  two  parties  are  involved  in  the  encryp- 
tion of  the  shared  key.  Therefore,  the  number  of  keys  which 
need   to   be   stored   in   the  KNF   is  reduced. 
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6.2      DATA  KEYS  (DK's) 


Data  keys  are  used  to  encrypt  data  belonging  to  one 
particular  user  or  data  shared  between  two  users.  DK's  are 
generated  by  the  key  generator  and  are  immediately  encrypted 
under  an  IK  XOR'ed  with  the  proper  identifier  pair.  The 
identifier  of  the  user  requesting  the  key,  who  is  also  the 
transmitter,  is  always  the  left  identifier  and  the  identif- 
ier of  the  intended  receiver  is  the  right  identifier  in  the 
identifier  pair.  When  encrypted,  DK's  may  be  sent,  kept  in 
unprotected  memory,  etc..  Initialization  vectors  are  em- 
ployed by  the  DES  algorithm  in  the  cipher  block  chaining 
(CBC),  cipher  feedback  (CFB),  and  data  authentication  (DAUT) 
modes  of  operation.  All  IV's  are  encrypted,  before  they 
leave  the  KNF ,  under  the  data  key  which  enciphers  the 
corresponding  data. 


7.      PASSWORD  AND  KEY  STORAGE 


Figure  2  shows  how  keys  appear  in  KNF  memory  at  host  1, 
in  host  1  system  memory,  and  in  the  memory  of  user  i  at  host 
1  . 


7.1      KNF  KEYS 

KNF  memory  contains  both  current  and  old  interchange 
keys  and  active  states  of  a  limited  number  of  users.  When 
the  interchange  keys  are  changed,  the  old  interchange  keys 
are  securely  stored  outside  of  the  KNF  along  with  their  ef- 
fective date.  With  the  addition  of  another  command  one 
could  encrypt  the  IK's  in  the  facility  master  key  to  reduce 
the  number  of  clear  keys  needing  protection.  The  current 
IK's  become  the  old  interchange  keys  and  the  new  interchange 
keys  become  the  current  IK's.  After  such  a  change,  the 
passwords  are  reencrypted  under  the  current  (new)  facility 
interchange  key,  and  the  users  are  told  to  reencrypt  their 
data  keys. 


7.2  PASSWORDS 

System  memory  contains  the  encrypted  passwords  for 
every  user.  Let  E[X](Y)  indicate  the  encryption  of  Y  under 
X  in  the  electronic  codebook  (ECB)  mode  of  operation.  Thus, 
E[IK1  XOR  (i  II  i)](PWi)  denotes  the  encryption  of  PW i  under 
IKl  XOR'ed  with  user  i's  identifier  pair,  (i  I  I  i).  IKl  is 
used     because      the     encrypted     passwords   are   from   the  system 
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memory  of  host  1  and  IKl  is  the  facility  Interchange  key  for 
host    1 . 

The  password  is  encrypted  under  IKl  XOR'ed  with  the  ap- 
propriate identifier  pair  to  protect  against  substitution. 
If  identifiers  were  not  used,  system  memory  might  appear  as 
f  o 1 lows : 


1.  E[IK1](PW1) 
j.  E[IKl](PWj) 


If  user  j  could  gain  access  to  system  memory,  he  might  alter 
it   as   f  o 1 lows : 


i.  E[IKl](PWj) 
j.  E[IKl](PWj) 


User  j  could  then  authenticate  as  user  i  by  submitting  his 
own  password  while  claiming  to  be  user  i.  If  identifiers 
are  used  as  in  figure  2,  then  E[IK1  XOR  (i  I  I  i)](PWj)  would 
be  calculated  upon  authentication  and  it  would  not  compare 
with  E[IK1  XOR  (j  ||  j )  ]  ( PW j )  which  was  substituted  as  user 
i's   encrypted  password. 


7.3     USER  KEYS 


User  i's  memory  contains  personal  and  shared  data  keys. 
Personal  data  keys  are  encrypted  under  the  facility  inter- 
change key  XOR'ed  with  the  user's  identifier  pair.  Personal 
keys  may  be  used  to  encrypt  files  and  other  private  data, 
but  cannot  be  shared.  User  i's  memory  also  contains  shared 
data  keys  encrypted  under  interchange  keys  XOR'ed  with  the 
concatenation,  (II),  of  user  i's  identifier  and  another 
user's  identifier.  (i  ! I  j)  uniquely  identifies  the  commun- 
ication parties.  If  (i  I  I  j)  were  not  used,  another  user 
could     substitute     his     own     data     key     encrypted     under  the 
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Interchange  key  and  then  be  able  to  decrypt  any  subsequent 
cipher.  Similarly,  when  user  j  receives  E[IKp  XOR  (1  1  I 
j)](DKij),  he  must  know  that  he  is  communicating  with  1, 
over  interchange  p,  to  correctly  decipher  DKij.  Thus,  the 
transmitter  is  prevented  from  posing  as  someone  else.  Since 
several  users  may  all  use  the  same  IKp  to  communicate,  this 
protection   is  critical. 

It  should  be  noted  that  it  is  the  system's  responsibil- 
ity to  enforce  any  restrictions  on  the  use  of  interchanges. 
For  example,  if  user  i  is  not  allowed  to  use  IKp  then  the 
system  must  enforce  this  arbitrary  restriction  by  not  load- 
ing IKp  for  user  i.  However  user  i  should  not  be  able  to 
subvert   the   restriction  by  key  substitution. 

One  could  argue  that  substitution  protection  is  not 
needed  for  system  memory  because  if  the  system  cannot  pro- 
tect system  memory,  it  probably  cannot  prevent  users  from 
changing  identity,  from  invoking  system  commands,  or  other 
security  threats.  This  may  be  true  but  encryption  should 
not  add  additional  possibilities  for  attacks.  In  user 
memory  the  substitution  threat  is  very  real  because  many 
systems  cannot  protect  one  user's  memory  from  another  user, 
and  even  if  they  could,  the  encrypted  keys  will  not  be  pro- 
tected. Encrypted  data  keys  may  be  stored  with  cipher  on 
unprotected  tapes  and  disks,  and  they  may  even  be  sent  out 
over   unprotected   communications  channels. 


8.      DEFINITION  OF  TERMS 


When  defining  our  commands,  the  terms,  initialize, 
reserve,  load,  store,  generate,  encrypt,  decrypt,  and  reen- 
crypt  will  be  used.  These  terms  should  be  defined  so  that 
the  meaning  of  the  commands  is  clear.  The  terms  actually 
represent   functions  which  operate   on  keys   or  passwords. 

init  ial ize;  Sets  a  password  to  a  starting  value  that 
should   be   changed   by  invoking   another  command. 

reserve:  Activates  a  user  by  loading  his  identifier 
into   the  KNF. 

load;  Takes  an  encrypted  key  or  encrypted  IV  from  the 
user,  decrypts  it,  and  puts  it  into  the  active  user  memory 
in   the  KNF. 
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store:  Places  an  encrypted  password  in  system  memory. 
Operates  on  PW. 

generate;  Calls  the  KNF  random  key  generator  which  gen- 
erates 56  unpredictable,  random  bits  that  are  combined  with 
eight  parity  bits,  as  required  by  the  DES.  The  result  is 
encrypted  under  an  interchange  key  XOR'ed  with  the  appropri- 
ate identifier  pair.  IV  generation  provides  a  full  64  ran- 
dom bits   before   encryption.      Operates   on  DK's   and  TV's. 

encrypt :  Encrypts  a  DK  or  PW  under  an  IK  XOR'ed  with 
the  appropriate  identifier  pair.  Uses  the  ECB  mode  of  en- 
cryption when  operating  on  keys.  "Encrypt"  also  refers  to 
enciphering   data   in  one   of   the   approved   DES  modes. 

decrypt :  Decrypts  an  encrypted  DK  or  PW .  "Decrypt" 
also  refers  to  deciphering  data  in  one  of  the  approved  DES 
modes . 

r eencr ypt :  Decrypts  an  encrypted  DK  or  PW  and  then  en- 
crypts it  under  a  new  IK  XOR'ed  with  the  appropriate  iden- 
tifier pair  in  order  to  avoid  the  reencryption  of  data  and 
the   reinitialization  of   passwords  when   IK's   are  changed. 


9.  COMMANDS 


This  section  describes  the  commands  or  protocols  which 
need  to  be  implemented  in  the  KNF  for  key  management  and 
data  encryption  purposes.  Besides  encryption,  decryption, 
and  authentication,  they  are  used  to  generate  keys  which  are 
given  to  the  user  and  to  provide  for  the  supersession  of  the 
keys  which  are  controlled  by  the  system.  The  commands  are 
invoked  by  a  command  name  followed  by  a  parameter  address 
list  of  passed  and  returned  values.  The  user's  identifier 
is  shown  as  a  parameter  only  when  it  must  be  supplied  by  the 
user     of  :   the   command.      For   some   commands   the   system  au- 

tomatically supplies  the  KNF  with  the  user's  identifier. 
Interchange  keys  must  be  loaded  into  the  KNF  before  commands 
are   executed . 
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9.1      INITIALIZE  PASSWORD    ( IPW ) 

IPW:  {pw} 

pw  =  password 


This  command  is  used  when  a  user  Is  first  put  on  the 
system.  The  password  is  encrypted  and  stored  in  host  system 
memory.  The  original  password  is  known  to  the  user  and  the 
security  officer.  The  user  submits  the  original  password 
when  he  first  authenticates  himself  to  the  KNF ,  then  he  im- 
mediately changes  his  password  to  a  secret  value,  known  only 
to  himself,  by  using  the  change  password  command,  CPW.  Only 
the  security  officer  who  Is  responsible  for  putting  new 
users  on  the  system  should  be  capable  of  Initializing  the 
passwo  rd  . 


9.2     REENCRYPT   PASSWORDS  (RPW) 


RPW:    {  } 


The  security  officer  executes  this  command  after  the 
interchange  keys  have  been  changed.  Each  encrypted  password 
stored  in  system  memory  Is  decrypted  using  the  old  facility 
interchange  key  and  encrypted  using  the  new  facility  inter- 
change key.  The  result  is  then  stored  back  in  system 
memory.  This  permits  a  user  to  authenticate  even  though  the 
interchange  keys  have  been  changed.  After  he  Is  authenti- 
cated and  active,  it  will  be  the  user's  responsibility  to 
reencrypt  his  data  keys  before  using  them  for  encryption, 
decryption,    or   data  authentication. 


9.3     RESERVE  ACTIVE   STATE  (RAS) 


RAS:    {ui,    pw ,    ss,  ua} 
ui   =   user  identifier 
pw  =  password 

ss   (system  status)     =  y  if  active  memory  Is  available 

=  n  otherwise 
ua   (user  =   0   if   ss   =  n 

aut hent 1  cat o r )      =   y  if   ss   =   y  and   PW  authenticates 

=  n  if   ss   =   y  and  no  authentication 


This  command  activates  the  user  by  loading  the  user's 
identifier  into  the  KNF.  Active  user  memory  must  be  avail- 
able and  the  user  must  authenticate  before  the  Identifier  is 
loaded.  No  other  commands  may  be  executed  by  the  user  until 
he  has  successfully  executed  RAS.  The  authentication  is  for 
use     of   the  KNF   and   is   independent   of   the   authentication  for 
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use  of  the  system.  Once  authentication  Is  complete,  the 
system  must  insure  that  other  users  cannot  execute  commands 
in  place  of  an  authenticated  user. 


9.4     LOGOUT  ACTIVE   USER  (LAU) 
LAU:  {ui} 

ui   =   user  identifier 

This  command  may  be  used  by  the  user  when  he  has  fin- 
ished using  the  KNF.  In  this  case  ui  is  optional.  The  com- 
mand removes  the  user  identifier  from  the  active  user  list 
maintained  in  the  KNF.  All  active  DK's  and  IV's  belonging 
to  the  specified  user  are  lost.  The  host  may  also  keep  a 
list  of  active  users  and  the  time  of  the  last  command  exe- 
cuted for  each  one.  If  a  user  has  not  executed  a  command 
after  a  reasonable  time  period,  then  the  host  may  use  LAU  to 
log  out  the  user.  The  user  may  still  be  logged  on  the  sys- 
tem but  he  will  have  to  repeat  the  RAS  command  to  use  the 
KNF.  The  system  may  also  periodically  decide  to  challenge  a 
user  by  requiring  him  to  reauthent icate .  Whenever  the  user 
logs  off  the  system,  the  LAU  command  should  automatically  be 
executed  . 


9.5     CHANGE   PASSWORD  (CPW) 

CPW:    {op,  np} 

op  =   old  password 

np  =  new  password 


This   command   is   used     to     change     passwords.        The  old 

password      is     authenticated     before   any  change   is  made.  The 

user  identifier  must  be  loaded  into  active  user  memory,  oth- 
erwise an  error  message  is  returned. 


9.6      GENERATE  DATA  KEY  (GDK) 

GDK:  {In,    sp,  ed} 

in  =  interchange  name 

sp  =  identifier   of   sharing  party 

ed   =  returned   encrypted   data  key 

ex.    (command   executed   by  user  i) 
in  =  p 
sp  =  j 

ed   =   E[IKp   XOR    (i    II    j) ] (DKi j) 
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This  command  Is  used  to  generate  new  keys.  The  iden- 
tifier of  the  user  invoking  the  command,  user  i  in  the  exam- 
ple, is  always  the  leftmost  value  in  the  concatenation  of 
the  sending  and  receiving  identifiers.  If  the  two  identif- 
iers are  equal,  then  the  key  is  personal  and  cannot  be 
shared.  This  command  may  not  be  executed  unless  the  user  is 
active.      Otherwise   an  error  message   is  returned. 


9.7      ENCRYPT   DATA  KEY  (EDK) 

EDK:    {ui,    dk,  ed} 

ui   =   user  identifier 

dk  =  data  key 

ed  =  returned  encrypted  data  key 
ex . 

ui  =  i 
dk  =  DK 

ed   =   E[IK  XOR    (i    I  I    i) ] (DK) 
IK  =   facility  interchange  key 


This  command  is  not  used  in  the  normal  functioning  of 
the  system.  It  need  only  be  used  for  communication  with 
someone  outside  of  the  system  who  doesn't  have  the  same  key 
generation  and  encryption  capability  or  for  generating  ci- 
pher encrypted  under  a  particular  key.  Since  this  command 
violates  the  security  criterion  that  no  clear  key  be  permit- 
ted outside  of  the  KNF,  it  is  recommended  that  only  the 
security  officer  be  allowed  to  execute  it.  It  may  be  best 
not   to   implement   this   command   at  all. 


9.8     LOAD   DATA  KEY  (LDK) 


LDK:  {kf,  in,  sp, 
kf    (key  function) 


in 
sp 


ed 

ex 
kf 
in 
sp 
ed 


ed} 
=  t 


if  key  is 
r  if  key  is 
s  if  ke y  is 
interchange 
identifier 


for   transmitted  data 
for   received  data 
for   personal   use  only 
name 

of   sharing  party 


=   encrypted   data  key 


(command   executed   by  user  i) 
t 
P 
j 

E[IKp   XOR    (i    II    j) ] (DKi j) 


ex.  (command  executed  by  user  i) 
kf   =  r 
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in  =  p 
sp  =  j 

ed   =   E[IKp   XOR    (j    I  I  l)](DKji) 

ex.    (command   executed   by  user  1) 
kf   =  s 

In  =   f    (facility   interchange  identifier) 
sp  =  i 

ed   =   E[IKf   XOR   (i    I  I  i)](DKii) 

This  command  loads  a  data  key,  either  shared  or  person- 
al, into  the  user's  active  state  in  the  KNF.  The  key  is 
stored  at  the  transmit  key  address  if  kf  =  t,  and  at  the  re- 
ceive key  address  if  kf  =  r.  If  user  i  executed  the  com- 
mand, then  kf  =  s  if  and  only  if  sp  =  i.  Otherwise  an  error 
message  will  be  returned.  When  kf  =  s  and  sp  =  i  the  data 
key  will  be  loaded  into  both  the  transmit  and  receive  loca- 
tions. The  user  must  be  active  before  this  command  can  be 
executed . 


9.9     GENERATE   INITIALIZATION  VECTOR  (GIV) 
GIV:  {ei} 

ei  =  returned  encrypted  initialization  vector 
ex . 

ei   =  E[DK](IV) 


This  command  is  used  to  generate  new  initialization 
vectors.  The  KNF  key  generator  generates  64  bits,  (56  ran- 
dom and  8  parity),  and  then  encrypts  them  under  the  data  key 
which  must  be  previously  loaded  at  the  transmit  address  in 
active  user  memory.  The  encrypted  IV  is  returned  to  the 
user.      The   data  key  may  be   either   personal   or  shared. 


9.10     LOAD   INITIALIZATION  VECTOR  (LIV) 
LIV:    {kf,  ei} 

kf  =   t   if    IV   is   for   transmitted  data 
=   r   if    IV   is   for   received  data 
=   s   if    IV  is   for   personal  data 

ei   =   encrypted   initialization  vector 

ex  . 

kf   =  t 

ei   =   E [DK] ( IV) 
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If   kf   =   t   then   the   data  key  at 
to     decrypt   the  encrypted  IV. 


used 
the  transmit  IV 
receive  address 
IV   is   stored  at 


the  transmit  address  is 
The  IV  is  then  stored  at 
address.  If  kf  =  r  then  the  data  key  at  the 
is  used  to  decrypt  the  encrypted  IV,  and  the 
the   receive   IV  address.     When  kf     =     s,  the 


transmit  data  key  is  used  to  decrypt  and  the  IV  is  placed  in 
both  the   transmit   and   receive   IV  locations. 


9.11      ENCRYPT    INITIALIZATION  VECTOR  (EIV) 
EIV:    {iv,  ei} 

iv  =  initialization  vector 
ei  =  returned  encrypted  IV 

ex . 

iv  =  IV 

ei   =   E[DK] (IV) 


This  command  is  not  necessary  because  one  can  always 
use  the  GIV  command  to  obtain  IV's.  However,  it  may  be  used 
with  the  EDK  command  for  communications  outside  of  the  sys- 
tem. Since,  in  the  KNS,  no  unencrypted  IV's  are  to  be  known 
by  users,  it  is  recommended  that  this  command  be  restricted 
solely  to  the  security  officer  or  omitted  completely.  The 
IV  is  encrypted  under  the  DK  previously  loaded  at  the 
transmit   key  address. 


9.12     REENCRYPT   DATA  KEY  (RDK) 


RDK; 
kf  = 


in  = 


{kf,  in,  sp,  ok, 
t  if  data  key  is 
r  if  data  key  is 
s   if   data  key  is 


rk} 

for   transmitted  data 
for  received  data 
for  personal  data 


sp  = 
ok  = 
rk  = 

ex . 

kf  = 
in  = 
sp  = 
ok  = 
rk  = 
IKp- 
IKp 


interchange  name 
identifier   of   shared  party 
old   encrypted   data  key 
returned   reencrypted   data  key 

(user   j   reencrypting   a  key  sent   to  him  by  user  i) 
r 

P 
i 

E[IKp 
E[IKp 
=  old 


=  new 


XOR    (i    II    j) ] (DKi j) 
XOR    (i    II    j) ] (DKi j) 
interchange  key 
interchange  key 


This   command   is   used  when   interchange   keys   are   changed.  It 
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reencrypts  data  keys  under  the  new  interchange  key  so  that 
the  data  protected  by  the  key  does  not  have  to  be  reencrypt- 
ed.  The  user  must  be  active.  Also,  kf  =  s  if  and  only  if 
sp  =   i   and   user   i   invoked   the  command. 


9.13      ELECTRONIC   CODEBOOK    (ECBE  AND  ECBD) 

ECBE:  {pt,  ct} 
ECBD:    {pt,  ct} 

pt   =   plain  text    (eight  bytes) 
ct   =   cipher   text    (eight  bytes) 


These  commands  are  not  required  in  the  normal  operation 
of  the  system.  They  are  provided  to  accommodate  future 
modes  of  DES  encryption  which,  as  yet,  have  not  been  con- 
sidered or  approved.  ECBE  encrypts  eight  bytes  of  plain 
text  at  pt  and  stores  the  result  in  ct.  ECBD  decrypts  eight 
bytes  of  cipher  at  ct  and  stores  the  result  at  pt.  Encryp- 
tion uses  the  transmit  DK  while  decryption  uses  the  receive 
DK.  A  data  key  must  be  previously  loaded  into  the  appropri- 
ate  active  state. 


9.14     DATA  AUTHENTICATION  (DAUT) 

DAUT:    {kf,   da,   nb ,   av ,  md} 

kf   =   t   if   data   is  transmitted 

=   r   if   data   is  received 

=  s  if  data  is  personal 
da  =  data 

nb  =  number   of   bytes   of  data 

av  =   returned   authentication  value    (eight  bytes) 
md  =  CBC    for  CBC  mode 
=  CFB   for  CFB  mode 


This  command  uses  DES  in  the  authentication  mode  to 
calculate  an  eight-byte  authentication  value  on  nb  bytes  of 
data  at  da.  If  kf  =  t  or  s  then  the  data  key  and  IV  which 
have  been  previously  loaded  into  transmit  active  storage 
will  be  used.  If  kf  =  r  the  key  and  IV  in  receive  key  ac- 
tive storage  will  be  used.  The  value  of  md  Indicates  which 
of   two   DES  encryption  modes   are  desired. 
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9.15 


CIPHER  BLOCK  CHAINING    (CBCE  AND  CBCD) 


CBC  E:    { pt ,    ct ,  nb} 
CBCD:    {pt,    ct,  nb} 
pt   =   plain  text 
ct   =   cipher  text 
nb  =  number   of  bytes 


For  encryption,  CBCE,  nb  bytes  of  data  starting  at  pt 
are  encrypted  in  the  CBC  mode  and  the  cipher  is  returned 
starting  at  ct.  For  decryption,  nb  bytes  of  data  at  ct  are 
decrypted  and  returned  to  pt .  If  nb  is  not  a  multiple  of 
eight,  then  the  CBC  mode  is  used  until  b  <  8  bytes  remain. 
The  final  b  bytes  are  encrypted  by  exclusive  or'ing  them 
with  the  first  b  bytes  of  the  next  DES  output  block.  DK  and 
IV  must  be  in  the  active  user  memory  otherwise  an  error  mes- 
sage is  returned.  Encryption  uses  the  transmit  IV  and  DK 
while   decryption  uses   the   receive   IV  and   DK . 


9.16      CIPHER   FEEDBACK    (CFBE  AND  CFBD) 


CFBE:    {pt,    ct,  nb} 
CFBD:    {pt,    ct,  nb} 
pt   =   plain  text 
ct   =   cipher  text 
nb  =  number   of  bytes 


As  described  for  the  CBC  commands,  nb  bytes  are  either 
encrypted  or  decrypted.  Encryption  uses  the  transmit  IV  and 
DK  while  decryption  uses  the  receive  values.  If  the  re- 
quired IV  and  DK  values  have  not  been  loaded  an  error  mes- 
sage will   be  returned. 


10.      DIGITAL  SIGNATURES 


10.1  RATIONALE 

Recall  that  digital  signatures  are  possible  with  public 
key  algorithms  because  one  cannot  decrypt  another  person's 
data  even  though  anyone  with  the  public  key  can  encrypt  data 
intended  for  that  person.  This  is  because  the  decrypt  key 
is  not  shared.  Since  the  KNF  combines  identifiers  with  in- 
terchange    keys      for     protection     against      substitution  and 
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employs  separate  encryption  and  decryption  key  storage,  one 
cannot  encrypt  data  In  a  key  that  was  generated  by  another 
user.  Therefore,  signatures  are  possible.  Suppose  user  i 
generates  a  key  using  the  GDK  command  and  sends  it  to  user 
j.      The   encrypted   data   key  would   be   of    the  form: 


ED   =   E[IKp   XOR    (i    II  j)](DKij) 


where  IKp  is  the  interchange  key  for  interchange  p  and  DKi j 
indicates  a  data  key  generated  by  i  for  transmission  to  j. 
Whenever  i  generates  a  key  his  identifier  is  always  leftmost 
In  the  identifier  pair  used  in  the  encryption  of  the  key. 
The  only  way  user  j  can  load  DKij  is  by  loading  it  as  a  re- 
ceive key.  Separate  transmit  and  receive  key  registers  are 
required.  If  j  tries  to  load  DKij  as  a  transmission  key  for 
the  encryption  of  data  going  to  i,  the  cryptomodule  will  use 
(j  II  i)  instead  of  (i  II  j)  when  decrypting  ED.  If  j  tries 
to  load  the  key  as  a  personal  key,  then  ( j  I  I  j)  will  be 
used.  (See  the  LDK  command  in  section  9,  COMMANDS.)  When 
DKij  is  loaded  as  a  receive  key,  only  the  decryption  com- 
mands  have   access   to  it. 


10.2  EXAMPLE 

Suppose   user   i   generates   ED  as   before.      He  may  then  use 
the   EIV  command   to   generate   an  encrypted    IV  of   the  form: 

EI   =   E [DKi  j ]  ( IV) . 


Next,  he  may  encrypt  a  signature,  S,  under  DKij  and  send  ED, 
EI,  and  S  to  j.  User  j  may  load  IV  and  DKij  in  the  active 
receive  state  by  the  LIV  and  LDK  commands,  and  decrypt  the 
encrypted  signature  to  recover  S.  There  is  no  way  that  j 
can  alter  S  to  a  particular  S'  and  encrypt  it  under  DKij  be- 
cause there  is  no  way  for  j  to  get  DKij  into  the  transmit 
data  key  active  storage. 

If  user  j  generates  his  own  encrypted  data  key,  it  will 
be  of  the  form:  E [ IKp  XOR  (j  I  I  i)](DKji).  He  may  encrypt  a 
signature  S'  under  DKjl  but  he  cannot  claim  that  it  came 
from  i  because  he  could  be  challenged  to  decrypt  the  en- 
crypted signature.  To  do  so  j  would  have  to  load  DKji  by 
submitting  E[IKp  XOR  (j  II  1)]  (DKjl)  to  the  LDK  command 
with  kf  =  r.  The  cryptomodule  would  not  load  the  correct 
DKji  because  it  would  use  (1  II  j)  instead  of  (j  II  i)  as 
the  identifier  pair.  Thus,  the  signature  would  be  garbled. 
Of      course,      user      j     may     send     a     signature      S'      to   user  i 
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encrypted  under  the  data  key,  DKjl,  in  a  similar  manner  as 
described   above.      (See   the   Illustration  below.) 


Separate   Transmit   and  Receive  Key  Storage 

User   1  User  j 

transmit:    IVl      DKl  j  S  >  receive:      IVl      DKl  j 

receive:      IV2     DKjl  <  S'        transmit:    IV2  DKjl 


Any  message  may  be  regarded  as  a  signature.  No  addi- 
tional keys  or  commands  are  required.  All  user  j  needs  to 
do  is  keep  E[IKp  XOR  (1  I  I  j)](DKlj),  E[DKij](IV),  and  the 
encrypted  signature  in  order  to  be  able  to  prove  that  S  was 
sent   to   him   from   1.      User   j   may  also  wish   to   keep   S   as  well. 


10.3      THE  AUTHENTICATION  VALUE  AS   A  SIGNATURE 

The  signature,  S,  may  be  an  entire  plain  text  message, 
but  it  may  be  undesirable  to  store  the  cipher  text  of  long 
messages.  In  such  cases  one  may  use  the  DAUT  command  to 
calculate  an  authentication  value  which  Is  a  cryptographic 
function  of  every  bit  of  data.  This  value  could  then  be 
used  as  the  signature.  Signatures  should  be  large  enough  to 
provide  adequate  security.  At  least  64  bits  are  recommend- 
ed. S  must  be  encrypted  as  in  the  previous  example.  Other- 
wise, the  receiver  could  modify  the  message  and  calculate 
the  correct  signature  for  the  new  message  using  the  DAUT 
command  with  the  correct  key  in  the  receive  active  memory. 
This  is  because,  unlike  encryption  and  decryption,  the  DAUT 
command  with  kf  =  t  gives  the  same  output  as  when  kf  =  r  as 
long  as  the  same  key  is  used  in  both  transmit  and  receive 
active  memory. 

If  one  is  not  concerned  with  proving  that  the  receiver 
did  not  modify  the  Incommlng  message,  then  the  authentica- 
tion value  need  not  be  encrypted.  Suppose  that  It  is  only 
necessary  that  the  receiver  knows  the  correct  transmitter  of 
the  message  and  that  it  has  not  been  altered.  The 
transmitter,  user  1,  may  generate  E[IKp  XOR  (1  I  I  j)](DKlj) 
and  E[DKij](IV),  and  load  DKlj  and  IV  into  transmit  active 
memory.  He  may  then  use  the  DAUT  command  with  kf  =  t  to 
generate  an  authentication  value,  AV .  User  1  may  then  send 
the   following   to  j: 
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clear   message,    E[IKp   XOR    (i    ||    j)](DKlj),    E[DKlj](IV),    AV . 


User  j  may  authenticate  the  message  by  loading  DKij  and  IV 
into  active  receive  state  and  then  using  DAUT  with  kf  =  r  to 
calculate  AV .  If  it  matches,  then  the  message  must  have 
come  from  i.  If  user  k  sent  the  message,  the  encrypted  data 
key  would  have  the  form:  E [ IKp  XOR  (k  II  j)](DKkj),  and  the 
authentication  value  would  be,  AV.  If  j  thought  that  it 
was  from  i,  then  when  he  executes  LDK,  (i  1 |  j)  instead  of 
(k  II  j)  would  be  used  to  decrypt  the  data  key.  Therefore, 
the  wrong  data  key  would  be  loaded. 


10.4      NONPUBLIC    KEY  VERSUS   PUBLIC   KEY  SIGNATURES 

A  digital  signature  capability  may  be  implemented  in 
the  KNS  because  the  receiver  of  an  encrypted  data  key  can 
only  load  the  key  into  his  receive  active  memory  and  can, 
therefore,  only  decrypt  with  it.  We  have  assumed  that  the 
KNF  of  each  host  is  physically  secured  from  all  users  and 
that  shared  keys  are  securely  distributed.  One  must  guard 
against  both  disclosure  and  substitution  of  keys.  If  one 
could  gain  knowledge  of  the  shared  key,  he  could  forge  all 
signatures  sent  between  both  facilities.  Of  course,  all 
keys  encrypted  under  the  shared  key  would  also  be  comprom- 
ised. Thus,  the  common  key  must  be  secured  at  the  transmit 
and  receive  KNF's.  With  public  key  algorithms,  the  secret 
key  requires  protection  against  disclosure  and  substitution 
while  the  public  key  must  be  protected  from  substitution. 
If  a  bogus  key  is  substituted  for  the  transmitter's  public 
key,    then   false   signatures   can  be   sent    to   the  receiver. 


11.      ILLUSTRATIVE  EXAMPLE 


11.1  INITIALIZATION 

Suppose  cryptography  were  to  be  added  to  a  computer 
network.  First,  each  host  would  have  to  be  provided  with  a 
KNF  and  the  necessary  interface.  Then  interchange  keys 
would  have  to  be  generated  and  distributed.  Once  the  inter- 
change keys  are  loaded  directly  into  the  c r yp t o f ac i 1 i t i e s 
and  the  authorized  users  are  assigned  unique  identifiers  and 
passwords,  the  security  officer  at  each  facility  can  ini- 
tialize the  passwords  of  the  authorized  users  by  using  the 
IPW  command. 
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11.2      THE  TRANSMITTER 


A  user  may  then  authenticate  and  become  active  by  using 
the  RAS  command.  He  could  change  his  password  to  a  secret 
value  known  only  to  himself  by  the  CPW  command.  Next  he  may 
want  to  generate  data  keys  using  GDK.  Suppose  he  is  on  host 
1,  then  GDK:  {1,  i,  ed}  generates  a  personal  data  key  and 
GDK:  {1,  j,  ed}  generates  a  shared  data  key  for  use  with 
user  j  at  host  1.  GDK:  {5,  k,  ed}  generates  a  shared  data 
key  for  use  with  user  k  over  interchange  5.  Interchange  5 
may  be   the   interchange  between  host    1   and  host  5. 

When  he  has  an  encrypted  data  key,  say  E[IKp  XOR  (i  1  I 
j)](DKij),  user  1  can  load  the  key  using  LDK.  LDK  with  kf  = 
t,  in  =  p,  sp  =  j,  and  ed  =  E [ IKp  XOR  (i  II  j)](DKij)  loads 
DKij  into  the  transmit  active  key  storage.  The  user  must 
keep  track  of  the  fact  that  kf  =  t  and  in  =  p  from  the  time 
the  key  is  generated  to  when  the  key  is  loaded.  If  the  key 
is  stored  for  future  use,  then  the  values  of  kf  and  in  re- 
quired by  the  LDK  command  should  also  be  stored.  User  i  may 
then  generate  an  IV  using  GIV  and  load  the  IV  into  the 
transmit  active  IV  storage.  After  he  sends  the  encrypted 
DKij  and  IV  to  j,  he  is  ready  to  encrypt  data  intended  for 
user  j.  Of  course  if  he  is  on-line  with  user  j,  he  must  es- 
tablish contact  with  j,  identify  himself,  and  send  him  the 
encrypted  DKij  and  IV.  If  he  is  on-line  he  should  require 
an  appropriate  response  from  j  to  insure  that  he  is  being 
received.  User  i  may  encrypt  in  either  the  CBC  or  C FB 
modes.  He  should  include  a  message  number,  the  date,  and 
the  time  in  his  plain  text  so  that  old  valid  messages  from  i 
to  j  cannot  be  played  back  to  j.  He  may  also  use  DAUT  to 
calculate  a  digital  signature  which  is  encrypted  before 
transmission. 

User  i  may  use  his  personal  encrypted  key,  E[IK1  XOR  (i 
I  I  i)](DKii)  to  encrypt  a  personal  file  and  then  store  the 
encrypted  key  with  the  cipher  or  in  a  personal  key  file. 
Finally,  he  can  log  out  of  active  status  using  the  LAU  com- 
mand. If  not,  the  system  should  automatically  log  him  out 
after  a  specified  time  period  or  when  he  logs  off  the  sys- 
tem,  whichever   comes  first. 


11.3      THE  REG  EIVER 

Once  user  j  is  active,  and  has  received  the  encrypted 
DKij,  IV,  and  data,  he  may  use  LDK  and  LIV  to  load  the  re- 
ceive active  storage.  He  can  then  decrypt  and  check  the 
signature  to  insure  that  it  is  correct.  Note  that  the  same 
data  key  may  be  used  for  both  encryption  and  digital  signa- 
tures. If  j  wishes  he  can  generate  a  DKji  to  communicate 
securely  to   i,   but   communications   from   j   to   i     will      not  be 
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encrypted  with  the  same  data  key  as  communications  from  i  to 
j  • 


11.4     KEY  SUPERSESSION 

Interchange  keys  are  generated  in  an  unpredictable 
manner  in  a  highly  protected  environment  outside  of  the  net- 
work. At  key  change  time,  the  current  IK's  are  stored  as 
old  IK's  and  new  IK's  are  entered  as  current  IK's.  The 
security  officer  uses  RPW  to  reencrypt  each  user's  encrypted 
password.  The  system  tells  each  user  when  he  becomes  active 
to  use  the  RDK  command  to  reencrypt  his  data  keys.  When 
keys  are  changed,  the  old  keys  no  longer  stored  in  the  KNF 
should  be  securely  stored  along  with  their  effective  dates. 
These  keys  may  be  needed  to  decrypt  old  files  or  to  validate 
old   signatures  whose   data   keys   were   not  reencrypted. 


12.  SUMMARY 


The  Key  Notarization  System  can  provide  secure  authen- 
tication and  encryption  with  limited  protocol  requirements 
in  a  variety  of  network  configurations.  Host  operating  sys- 
tems must  protect  plain  text  and  maintain  user  identity  once 
authentication  is  complete,  but  the  host  need  not  protect 
keys  from  either  disclosure  or  substitution.  A  set  of  KNF 
commands  is  defined  for  key  management  functions  as  well  as 
for  the  approved  DES  modes  of  operation.  The  secure  distri- 
bution of  data  keys  is  attained  by  encryption  and  the  use  of 
identifiers  for  key  notarization.  The  system  features  on- 
line and  off-line  applications,  local  key  generation,  and  a 
digital   signature  capability. 
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APPENDIX 


The  key  and  Initialization  vector  generator  described 
here  has  not  been  analyzed  either  for  its  quality  as  a  pseu- 
dorandom number  generator  or  for  its  security.  It  is  merely 
presented  as  an  example  which  may  be  altered  or  replaced  at 
a   later   date . 

E[X](Y)  represents  the  DES  encryption  of  Y  under  key, 
X,  In  the  ECB  mode.  Let  FIK  be  the  facility  interchange 
key,  and  let  V  be  a  seed  value.  V  may  be  initially  set  to 
any  number.  Let  DT  be  the  date-time  word  that  is  passed  to 
the  KNF  from  the  host  on  each  key  or  initialization  vector 
generation  command.  A  64-bit  vector,  R  is  generated  as  fol- 
lows : 

I   =   E[FIK] (DT) 

R   =   E [FIK] (I   XOR  V) 

and   a  new  V   is   given  by  V  =   E[FIK](R  XOR  I). 

If  the  GDK  command  made  the  call,  then  a  data  key  is 
created  by  resetting  every  eighth  bit  of  R  so  that  the  modu- 
lo 2  sum  of  the  bits  of  each  8-bit  byte  is  odd.  If  the  GIV 
command  made  the  call,  R  is  used  directly  as  the  64-bit  ini- 
tialization vector. 
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FIGURE  1: 
A  FOUR  HOST  NETWORK 
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Figure  2; 
Password   and  Key  Storage 
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